Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/smtpext/smtpext-minutes-91jul.txt

Text File | 1993-02-17 | 8.8 KB | 230 lines

CURRENT_MEETING_REPORT_


Reported by Greg Vaudreuil/CNRI

SMTPEXT Minutes

Agenda

   o Where are we, and where are we going?

      -  Just send 8 bits
      -  Negotiate 8 bits
      -  Do nothing

   o If negotiated, how to do transport conversion?

      -  Encapsulation
      -  Message Munging

   o Defining the ``New'' SMTP


Where are We, and Where are We Going?

The Chair began this meeting by reviewing the history of this Working
Group and the goals as they have evolved.  This meeting was called in
part to affirm the progress on the mailing list in a room where true
give-and-take could be had.  In a nutshell, the SMTP extensions were
first motivated by those who want to be able to send 8 bit textual data
via SMTP. This is already being done in practice.  The group discussed
the goals and in light of current deployment of non-standard systems,
refined the goals to include a more general extension to the SMTP
protocol.

There was a general feeling among many participants that a simple
extension to support only 8 bit textual data was not worth the
transition costs involved in upgrading the system.  There are however
many reasons to update the mail transport protocol.  Among these needs
are arbitrary options negotiation, binary transport, maximum message
length restrictions, and ``real'' authentication.  A sampling of
opinions from the meeting:


   o The Europeans REALLY REALLY want to send their stuff without
     encoding it.  They REALLY REALLY want to do this via a negotiated
     option so they could have an assurance that the mail was delivered
     as intended.

   o Existing software vendors, Prime, Sun, and others not so visible,
     do not feel that 8 bit textual data transmission is worth the costs
     of modification.  This was strongly asserted at the St.  Louis
     IETF, while the mailing list (led in part by the Chair) went off
     and wrote an SMTP extensions specification for 8 bit mail anyway.

                                   1





   o Even the multi-part multi-media mail people could agree with the
     assertion that the world would be a better place if binary data
     could be sent.


After a bit of soul searching, the group agreed to work on a complete
change to SMTP which would allow future new features to be added via
negotiation, and would allow binary and 8 bit transport.

Interworking of 7 bit, 8 bit and Binary Transport.

Now that the Working Group decided to move ahead on new functionality,
the next question to be solved was the definition of an interworking
strategy.  Fortunately for this group, the Message Format Extensions
group decided to keep nested transport encodings in their proposed
standard document.  While this feature is tentative and subject to the
results of implementation experience, it provides a mechanism for
initial implementations.  After a short amount of discussion, the group
decided to write a specific, well defined conversion algorithm which
specifies that messages which need to be converted between transport
environments, MUST be encapsulated into a new message of the form
defined in the message format extensions document.  This encapsulation
will result in a message with a single body part MESSAGE with an
appropriate transport encoding.  If the message format document is
changed to make illegal nested transport encodings, this issue will have
to be revisited.

The strict definition of the transport encoding to be used was
discussed, and the consensus of the group was that a strict
specification of which transport encoding to use could not easily be
made to work.  The best approach for an implementor is to scan the
document and determine statistically whether it would be better to
encode the entire message in a Base 64 encoding or escape the few
offending characters via a quoted printable encoding.

Defining the ``New'' SMTP

The Working Group began work on the new SMTP version.  It was argued
that the greatest change necessary is to define a negotiation mechanism
for new capabilities.  Some of these capabilities are:


   o 8 bit Text
   o Binary Transport
   o Authentication
   o Delivery Notification
   o Message Size Negotiation
   o Explicit Batch Mode


Several modifications to the protocol were suggested that were
feature-independent.  Among the suggestions were:

A Second TCP Connection for Data

                                   2





A second data connection would make it possible to do data
checkpointing, and would reduce the cost of sending binary data.
Drawbacks include the overhead of opening and tearing down a second
channel, and running SMTP over non-tcp single-channel protocols such as
X.25.  The Working Group decided not to pursue this approach.  The cost
of sending binary data over the existing channel either by escaping or
byte counting was found to be preferable over the cost of opening a new
TCP connection.  Checkpointing in FTP is still not widely used, and is
considered by this group to be of dubious value.

Asynchronous Operation

Currently SMTP commands are batched by several implementations and sent
in a single packet to save round-trips.  This has been demonstrated to
work with known SMTP implementations.  An extension to tag the data and
the commands to allow full asynchronous operation was proposed.  This
offers very significant improvements in throughput by reducing packet
per verb to control packet per session in the best case.  The Working
Group debated this point and concluded that full asynchronous operation
would push SMTP into a not-so-simple MTP.

A Negotiation Infrastructure

The group agreed that a mechanism needs to be defined to allow the
extension of SMTP. The current approach of this Working Group has been
to add functionality via the addition of new verbs.  While this approach
is seen by some to be the strait forward answer, using new verbs can
cost significant time in round-trip delay while playing a network
version of the old card game ``go-fish''.  Other suggestions included a
telnet like negotiation.

The Working Group began exploring features of a new negotiation
mechanism for the SMTP protocol.  Among the possible goals are:


   o Symmetry -- should the receiver and the sender both request an
     option?
   o Batchable -- should more than one option be negotiated at a time?
   o Duration -- per-session, per message, or per-recipient?
   o Default behavior - should the default be better than current SMTP
     service?


Symmetry:  Symmetry was suggested as a means to allow authentication of
the sender by the receiver.  At this time there is no formal
authentication mechanism, and the negotiated use of CAT or Kerberos was
seen as a good thing.  After lengthy debate, the group decided that
authentication of the sending SMTP in a store and forward network was of
dubious value and was not worth the added complexity a symmetric
negotiation entails.

Batchable:  Batching negotiated parameters offers great savings in
round-trip times.  It is not clear how this would work in practice, but
the group felt that this was a good goal.

                                   3





Duration:  This was a tricky subject.  Currently SMTP does not provide
any information about the users environment.  Any use of per-recipient
or per-message requires the keeping of more knowledge about the end-user
than the system has now.  It was not clear to the group that any
per-recipient options exist that could not be duplicated by a local
delivery agent.

Default:  This turned into a no-brainer.  The group unanimously felt
that the new SMTP needed to be backward compatible, and in the case of
complete failure of any negotiation, the mail would continue to go
through as specified in RFC 821 and HR.

The meeting concluded with the discussion of several specific
negotiation strategies.  Several attendees volunteered to write up
proposals for negotiation mechanisms.  This discussion will be continued
on the mailing list.

Attendees

Peter Boos               [e-mail]
James Conklin            [e-mail]
Johnny Eriksson          [e-mail]
Erik Fair                [e-mail]
Ned Freed                [e-mail]
Olafur Gudmundsson       [e-mail]
Russ Hobby               [e-mail]
Neil Katin               [e-mail]
Darren Kinley            [e-mail]
Jim Knowles              [e-mail]
Vincent Lau              [e-mail]
Eliot Lear               [e-mail]
Jack Liu                 [e-mail]
Joseph Malcom            [e-mail]
Leo McLaughlin           [e-mail]
Keith Moore              [e-mail]
Michael Patton           [e-mail]
Jan Michael Rynning      [e-mail]
Mark Saake               [e-mail]
Harri Salminen           [e-mail]
Keld Simonsen            [e-mail]
Gregory Vaudreuil        [e-mail]



                                   4